Mobile IP (MIP) is described in a number of documents developed in the IETF (www.ietf.org). MIP provides for mobility management for a mobile node (MN) Home address (HoA) by tunneling packets at a Home Agent (HA) towards/from a MN Care of Address (CoA), at which the MN HoA is routable. MIP signaling between the MN and the HA, maintains the MN CoA/MN HoA binding at the HA, and updates it to each new CoA value as the MN moves between Access Routers, and hence across the routing topology.
The MIP HA acts as both the end point for MIP signaling and also as the endpoint for MIP tunnel forwarding. The HA also issues routing adverts for the HoA prefixes at that HA, from which MNs are allocated HoAs. The MIP HA must have a security association with each MN, and also with any Foreign Agent through which the signaling traverses. This is to ensure that binding changes can only be made by authorized MIP nodes. The end result is typically a HA router platform with significant forwarding, mobility signaling and security processing responsibilities. The HA also has timely visibility of the topological location and movement of the MN which can be useful for Location Based Services, and for presence management. However, the processing and publishing of such information to application services places additional significant burdens on HA nodes. A further problem with HAs is that from a security and management perspective they should be ideally located behind a firewall in the applications server farm of the operator but this causes high volume, low value traffic to trombone through the firewall twice to visit the HA and be onward forwarded to the MN.
An improved MIP HA architecture decomposes the HA functions, to separate and distribute the MIP signaling and tunneling end-points. The HA Control Node (HACN) manages the mobility signaling with the MN and FA whilst one or more HA Tunneling Nodes (HATNs) provide forwarding for packets towards the HoA of the MN. In such an approach multiple HATNs may be operated under the control of a single HACN.
However, even when using multiple HATNs, the failure of the HACN still renders all MNs that undertake mobility signaling via that HACN unable to update their mobility location while it may still be possible for each HATN to forward packets correctly to MNs that remain at the same location. Therefore whether a traditional HA or a decomposed HA (HACN/HATN) is used for mobility management, the failure of the HA/HACN results in significant problems.
A redundant pair of conventional HAs, synchronised with Virtual Router Redundancy Protocol (VRRP), is generally considered at the present time to be the optimal deployment configuration for an IP mobility domain, with any HA failure then being hidden from the MN/FA by the synchronization protocol with the redundant HA. As the need grows to integrate mobility events with value-adding processes, including external application servers, this centralized (hot standby) architecture becomes more and more of a bottleneck as the amount of state to be synchronized grows. Locating the two HAs in the same location renders them vulnerable to geographical/environmental failures (weather, power, attack, flood etc). In addition, the synchronization protocol performs increasingly poorly as the HAs are moved apart (increasing signaling delay) because the bindings and other state in each virtual HA become desynchronized.
The use of multiple physical HAs, that do not require synchronization, is problematic because the HA manages address allocation and forwarding and so a change of HA forces a change in the MN HoA creating major disruption to ongoing sessions. In addition, the HA address and HoA is known by the MN and the FA, and so a change in HA is exposed to the MN and relies on the MN acting promptly to detect the failed HA and then move across to the spare HA. No known solution exists for that spare HA being able to provide forwarding for the HoA that was being used at the failed HA. In addition, relying on the MN to perform the recovery from the failed HA is expensive on the air-link, slow and means that customers are overly exposed to operator failures and operators rely on terminal software for the timeliness of that recovery.
In view of the above discussion, it should be appreciated that there is a need for improved methods of providing packet forwarding control functions and/or packet forwarding functions, e.g., HA type functions, in a manner that provides both fault tolerance and avoids many of the problems/risks associated with locating two home agents in close proximity while avoiding some or many of the synchronization and/or control issues associated with using two conventional HAs that are located at distances from one another.